Don't use a PR number as the issue prefix, things get confused. Please can you create an issue for this PR, and add a NEWS entry?

Please can you use a pyperformance benchmark, and update the PR with the benchmark code and results? Microbenchmark results should show a reasonably large performance improvement, which this PR hopefully will based on the preliminary numbers you've shown.

A

We need to be very careful that we're not changing semantics with this. We've had that problem before with comparisons (although of course now I can't find the issue). I don't think we added tests for this, because we didn't find the problem until after we'd released the code.

@ericvsmith so we need set of tests that pass prior to this change?

Potentially relevant "semantics" you mention may be shown in the tests for this change in #582?

I'm specifically thinking of #128294. We don't want to do something like that again. I haven't looked at this change closely, I just want to be extra careful.

@ericvsmith Thanks for that info, I looked into the situation a bit and it seems that since the behavior of 3.13 for __eq__ is accepted as intended now that this may actually fix things to be consistent with that.

I will file an issue for this order=True discrepancy on 3.13 and link this PR.

@dataclasses.dataclass(order=True, slots=True)
class Data:
    a: float

class Obj:

    __slots__ = "a",

    def __init__(self, a: float):
        self.a = a

    def __eq__(self, other):
        if self is other:
            return True
        if self.__class__ is other.__class__:
            return (
                self.a == other.a
            )
        return NotImplemented

    def __lt__(self, other):
        if self.__class__ is other.__class__:
            return self.a < other.a
        return NotImplemented

    def __le__(self, other):
        if self.__class__ is other.__class__:
            return self.a <= other.a
        return NotImplemented

    def __gt__(self, other):
        if self.__class__ is other.__class__:
            return self.a > other.a
        return NotImplemented

    def __ge__(self, other):
        if self.__class__ is other.__class__:
            return self.a >= other.a
        return NotImplemented


nan = float("nan")

assert not (Data(nan) < Data(nan))
# assert not (Data(nan) <= Data(nan)), "fails on 3.13 even though {<, ==} are both False"
assert not (Data(nan) > Data(nan))
# assert not (Data(nan) >= Data(nan)), "fails on 3.13 even though {>, ==} are both False"
assert (Data(nan) != Data(nan))
assert not (Data(nan) == Data(nan))

assert not (Obj(nan) < Obj(nan))
assert not (Obj(nan) <= Obj(nan))
assert not (Obj(nan) > Obj(nan))
assert not (Obj(nan) >= Obj(nan))
assert (Obj(nan) != Obj(nan))
assert not (Obj(nan) == Obj(nan))

@AA-Turner thanks, added those details except the performance part. Rebranded the PR as a fix now that the linked issue is related to aligning behavior semantics with #104904

@ericvsmith I added tests to show the behavior and how it aligns with the 3.13+ equality methods. Some of the assertions would fail on main branch as described in the linked issue.